home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 245 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: bgibbons@best.com (Bill Gibbons)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Make type_info name() distinct?
  5. Date: 02 Feb 1996 17:53:46 PST
  6. Organization: -
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <199602030146.RAA14333@shellx.best.com>
  9. References: <v01530500ad36a19a2831@[194.163.74.11]>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Fri, 2 Feb 1996 17:46:33 -0800
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMRLAaky4NqrwXLNJAQHrOQH/T82PLhs5teBHfS1gCSeTsVTNfjL1XjHe
  14.     zjcx/ed2iFir3P6RBbVqOs/pp4UjBJTKBSlpRIJ2OwCL5S8Mk53sVg==
  15.     =UCgg
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. In article <v01530500ad36a19a2831@[194.163.74.11]>,
  19. dirk@becker.adviser.com (Dirk Becker) wrote:
  20.  
  21. > Is there any detailed specification added to the name() member of
  22. > type_info objects or is it still just implementation dependent?
  23. > 
  24. > Why not ensure to have distinct names for different classes?
  25. > Could it be possible to have even distinct name()s for nested classes
  26. > bearing the same name but different enclosing classes?
  27. > What about classes with the same name but in different namespaces?
  28. > Or is "9.10 Nested type names" [class.nested.type] even applied to
  29. > RTTI names?
  30.  
  31. The original RTTI papers imply that the complete name, together with any
  32. qualification and/or template arguments, should be used.  For example:
  33.  
  34.     mytemplate<X>
  35.     mynamespace::outer::inner
  36.  
  37. But the papers did not explicitly specify how this was to be done, so the
  38. current draft leaves that implementation dependent.
  39.  
  40. I wrote a proposal for standardizing the names, but there was only
  41. lukewarm interest.  This is partly because there are some problems:
  42.  
  43.   * Function parameter types:
  44.  
  45.          does --typeid(void (*)(int,int).name()-- yield
  46.  
  47.                "void (*)(int,int)"
  48.           or   "void(*)(int, int)"
  49.           etc.
  50.          (possible answer - just specify a canonical form)
  51.  
  52.   * Template arguments:
  53.  
  54.          does --typeid(T<A,B>).name()-- yield
  55.  
  56.                "T<A,B>"
  57.           or   "T<A, B>"
  58.           etc.
  59.           (possible answer - just specify a canonical form)
  60.  
  61.   * How are unnamed types handled?  For example:
  62.  
  63.          struct { int x; } y;
  64.          typeid(y).name();
  65.          (possible answers - implementation dependent
  66.                              invented names based on ordinals)
  67.  
  68.   * How are local types handled?  For example:
  69.  
  70.          void f() { struct A { }; typeid(A).name(); }
  71.          void g() { struct A { }; typeid(A).name(); }
  72.  
  73.          Are these two names the same?
  74.          (possible answers - yes, they are the same
  75.                              implementation dependent
  76.                              invented names based on function signature
  77.                                but only unique for external functions)
  78.  
  79. There is some chance that some canonical form will be recommended
  80. in a non-normative annex in the standard.
  81.  
  82. -- 
  83. -- Bill Gibbons
  84.    bgibbons@best.com
  85. ---
  86. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  87.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  88.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  89.